Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.022

Internet Message Format | 1994-06-09 | 91KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-022
Date: Mon, 2 May 94 13:41:49 MET DST

C.S.M.P. Digest             Mon, 02 May 94       Volume 3 : Issue 22

Today's Topics:

        Best way to handle Moveable Modals?
        Can you set the folder in which SFGetFile will open?
        Control Panels items font
        Fixed Point Math on PowerMac
        Keeping DialogPtr's in RAM after startup...
        Metrowerks News from MacWEEK
        WaitNextEvent Emulated on PoMac!?
        X2Fix code generation bug still in SC++ 7.0



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (mahboud)
Subject: Best way to handle Moveable Modals?
Date: Fri, 08 Apr 1994 12:50:48 -0800
Organization: AG Group, Inc.

Hi.

What's the best way to handle moveable modals?  Specifically, I want to be
able to do process(application) switches (i.e. put my app in the
background, while a moveable modal is foremost).

Prefereably I want to be able to do this by changing a filterproc, not by
going through the main event loop.  I have tried putting WaitNextEvents in
the ModalFilterProc, but it did some weird things.  One reason I want to
use the filterproc is that I still want to call ModalDialog to handle the
events in the window, so I don't have to worry about updates, etc..

Thanks,

mahboud

ps.  I already handle moving the dialog from within my filterproc.

- -------------------------------------------------------------
Mahboud Zabetian
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp

+++++++++++++++++++++++++++

>From [e-mail] (mahboud)
Date: Sun, 10 Apr 1994 14:50:00 -0800
Organization: AG Group, Inc.

In article I wrote:
> What's the best way to handle moveable modals?  Specifically, I want to be
> able to do process(application) switches (i.e. put my app in the
> background, while a moveable modal is foremost).
>
> Prefereably I want to be able to do this by changing a filterproc, not by
> going through the main event loop.  I have tried putting WaitNextEvents in
> the ModalFilterProc, but it did some weird things.  One reason I want to
> use the filterproc is that I still want to call ModalDialog to handle the
> events in the window, so I don't have to worry about updates, etc..
>

In response to all the mail I got, telling me to use the main event loop
and not a filter proc, I'd like to clarify a point.

I'd rather not use the main event loop, as I am retro fitting applications,
one modal dialog at a time, and by adding to the filter proc of each
existing dialog (most share the same filterproc), I would be making fewer
changes overall.

-mahboud
- -------------------------------------------------------------
Mahboud Zabetian
[e-mail]
ag group, inc.
2540 camino diablo, suite 200
walnut creek, ca 94596
510-937-7900 voice
510-937-2479 fax
510-937-6704 ara
ftp.aggroup.com anonymous ftp

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 13 Apr 1994 23:24:46 GMT
Organization: Apple Computer

mahboud, [e-mail] writes:
> I'd rather not use the main event loop, as I am retro fitting applications,
> one modal dialog at a time, and by adding to the filter proc of each
> existing dialog (most share the same filterproc), I would be making fewer
> changes overall.

Given that you can't make them "modeless dialogs that won't let you switch to
another window", you can get most of the functionality by modifying the
filterProc. Users still won't be able to switch layers while your dialogs are
up, unfortunately, because ModalDialog disables layer switching.

In your filterProc:
* On mouseDown, call FindWindow. If the click is on the title bar of the
window, call DragWindow. Then change the event record to a nullEvent.
Optionally, you can also respond to command-clicks in other app windows'
title bars by dragging those windows without activating them.
* On update, check whether the target window is an application window other
than the dialog. If so, call whatever application routine handles update
events. If you don't do this, moving the dialog will leave permanent white
areas behind where the dialog used to be, as well as denying background time
to other apps (see the tech note "Pending Update Perils".)

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Fri, 15 Apr 1994 09:46:34 +0800
Organization: NCRPDA, Curtin University

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

>mahboud, [e-mail] writes:
>> I'd rather not use the main event loop, as I am retro fitting applications,
>> one modal dialog at a time, and by adding to the filter proc of each
>> existing dialog (most share the same filterproc), I would be making fewer
>> changes overall.
>
>Given that you can't make them "modeless dialogs that won't let you switch to
>another window", you can get most of the functionality by modifying the
>filterProc. Users still won't be able to switch layers while your dialogs are
>up, unfortunately, because ModalDialog disables layer switching.

If you're going to do this, why not just write your own implementation of
ModalDialog?  It's not that complicated, you just call WNE, and handle
events (passing most of them to IsDialogEvent and DialogSelect).  You have
the same disadvantage of ModalDialog in that you aren't going thru your
main loop, so you can't handle AppleEvents and other things that would
normally get processed.
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Fri, 15 Apr 1994 18:53:08 -0500
Organization: I-Link, Ltd.

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> In article <[e-mail]>, Jens Alfke
> <[e-mail]> wrote:
>
> >mahboud, [e-mail] writes:
> >> I'd rather not use the main event loop, as I am retro fitting applications,
> >> one modal dialog at a time, and by adding to the filter proc of each
> >> existing dialog (most share the same filterproc), I would be making fewer
> >> changes overall.
> >
> >Given that you can't make them "modeless dialogs that won't let you switch to
> >another window", you can get most of the functionality by modifying the
> >filterProc. Users still won't be able to switch layers while your dialogs are
> >up, unfortunately, because ModalDialog disables layer switching.
>
> If you're going to do this, why not just write your own implementation of
> ModalDialog?  It's not that complicated, you just call WNE, and handle
> events (passing most of them to IsDialogEvent and DialogSelect).  You have
> the same disadvantage of ModalDialog in that you aren't going thru your
> main loop, so you can't handle AppleEvents and other things that would
> normally get processed.

I've done this, and it's not too bad.  Makes retrofitting and still getting
the AppleCorrect(tm) behavior fairly easy.

With a little thought (and depending on the design of your application),
you can even get this secondary event loop to handle high level events (if
appropriate).  This is left as an exercise for the reader.

_troy
//////// //////___Troy [e-mail]__
//
  //    //       Infinity Systems ; West Des Moines, Iowa
//
 //    //  //  "Good news is just life's way of keeping you off balance" //
//    //////___________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Vampire)
Date: Sun, 17 Apr 1994 09:10:37 GMT
Organization: Pennangalan Software


I've been watching this thread for a few days now...

The way I do this is a little Windows-inspired (don't all flame me, please...I
HATE Windows...unfortunately my employers don't...

I have a main event loop. (Surprise!). When I want to go Movable Modal, I get
the module with the Modal to create its Window as usual, then get it to call a
function 'RegisterModal', with the main control module. This function simply
registers a second event-loop (particular to the movable modal concerned), and
sets an internal Boolean, 'InModal', to TRUE.

The main event-loop examines InModal, and if it is TRUE, ALWAYS passes the
event onto the registered secondary event loop for handling. The secondary
function returns TRUE or FALSE, depending upon whether it handled the event or
not. If it didn't, the main-event loop can handle it as normal.

That way, the Movable Modal code gets to react to events concerning it, ignore
events that don't (e.g. update a background window), and *pretend* to react to
events it wants ignored (i.e. mousedowns in another Window of the same
application).

=============================================================================
                                  |"If I knock on your door, you're a fool;
         VAMPIRE                  | if you invite me in, you're a dead fool"
  (Pennangalan Software)          |  My dust resides @crypt.demon.co.uk
=============================================================================

---------------------------

>From [e-mail] (David Blume)
Subject: Can you set the folder in which SFGetFile will open?
Date: Fri, 15 Apr 1994 00:28:03 GMT
Organization: Gokuraku Videos - Wollongong Dept.

Can you set the folder in which SFGetFile and SFPutFile will open?

--David
+---------------------------------------------------------------+
|  David Blume    |  "I get tired thinking of all the things I  |
|  [e-mail]  |   don't want to do."  --Bukowski, _Barfly_  |
+---------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Paul DuBois)
Date: 14 Apr 1994 20:38:06 -0500
Organization: Castra Parvulorum

>From article <[e-mail]>, by [e-mail] (David Blume):
> Can you set the folder in which SFGetFile and SFPutFile will open?

This is how I do it if I have an FSSpec:

    CurDirStore = fss.parID;
    SFSaveDisk = -fss.vRefNum;

Note that you use the negative of the vRefNum.

I think this is horrendous, because it involves assigning values to
two low-memory globals.  Is there another way to do it?

--
Paul DuBois
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: 17 Apr 1994 01:50:56 +0200
Organization: Contributed Software GbR

In article <[e-mail]>,
Paul DuBois <[e-mail]> wrote:

>     CurDirStore = fss.parID;
>     SFSaveDisk = -fss.vRefNum;
>
> I think this is horrendous, because it involves assigning values to
> two low-memory globals.

Exactly.

> Is there another way to do it?

If you can require System 7, yes. (the original poster asked about
SFGetFile, so maybe this won't help him). Do a CustomGetFile; in your
dlgHook you check for sfHookFirstCall, and if you receive it, change your
reply record to whatever location you want to have displayed, and return
sfHookChangeSelection. This has the additional advantage that you can
specify a certain file to be selected.

(You'll have to pass the address of the reply record in the yourDataPtr
parameter if you don't want to make it a global var).

_____________________________________________________________________
Stefan Kurth              Berlin, Germany              [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 17 Apr 1994 21:24:12 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <2optl1$[e-mail]>,
Stefan Kurth <[e-mail]> wrote:

>dlgHook you check for sfHookFirstCall, and if you receive it, change your
>reply record to whatever location you want to have displayed, and return
>sfHookChangeSelection. This has the additional advantage that you can
>specify a certain file to be selected.

If you want this to work, you also have to set sfScript to 0.
I know it isn't mentioned in Inside Mac, but it's true. Took
me days to figure out (thanks to Jon Watte's FAQ for pointing
it out!)

--
Francois Pottier
[e-mail]

---------------------------

>From [e-mail] (Alex Metcalf)
Subject: Control Panels items font
Date: Fri, 8 Apr 1994 23:20:33 GMT
Organization: Demon Internet


This is a slightly dumb question...

How do you set the font for the DITL resource for a control panel? I've
often opened up ResEdit to find the control panel's DITL displayed in
Geneva 9 (such as check boxes and static text), but I can't seem to change
from the default Chicago 12.

Thanks,


Alex

--
Alex Metcalf, Mac programmer in C, C++, HyperTalk, assembler

Internet, AOL, BIX: [e-mail]            "Surely you
AppleLink:          [e-mail]@internet#   can't be
CompuServe:         INTERNET:[e-mail]    serious?"
Delphi:             [e-mail]@inet#
FirstClass:         [e-mail],Internet   "I'm serious...
Fax (UK):           (0570) 45636                         and don't call
Fax (US / Canada):  011 44 570 45636                     me Shirley."

+++++++++++++++++++++++++++

>From [e-mail] (Barton Jaques)
Date: 10 Apr 1994 20:43:53 GMT
Organization: Wimsey Information Services

In article <[e-mail]>,
[e-mail] (Alex Metcalf) wrote:

> How do you set the font for the DITL resource for a control panel? I've
> often opened up ResEdit to find the control panel's DITL displayed in
> Geneva 9 (such as check boxes and static text), but I can't seem to change
> from the default Chicago 12.

In your cdev code, just set TextFont() to whatever you desire, before any
drawing is done. Be sure to change it back whenever your code exits.
You can change the ResEdit view font under "View As …" in the DITL editor.
That only changes how it appears in ResEdit, though; it has no effect on
the DITL resource contents.
--
[e-mail]

+++++++++++++++++++++++++++

>From Reid Ellis <[e-mail]>
Date: Sat, 16 Apr 1994 03:47:27 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Alex Metcalf <[e-mail]> asks:
|How do you set the font for the DITL resource for a control panel?

Barton Jaques <[e-mail]> replies:
|In your cdev code, just set TextFont() to whatever you desire, before
|any drawing is done. Be sure to change it back whenever your code
|exits.

Alternatively, include a 'finf' resource, id=-4049, and set its three
16-bit ints to the font id, style, and size you want [in that order].

Caveat: I've been having problems with 'useWFont' popup menus in
combination with the 'finf' resource under System 7.0 [it's fine under
System 7.1]

Reid
--
- -
Reid Ellis, Alias Research Inc.
[phone] <[e-mail]>

---------------------------

>From Willie Rauchwerger <[e-mail]>
Subject: Fixed Point Math on PowerMac
Date: 6 Apr 1994 21:22:02 GMT
Organization: OU Health Sciences Center

My image manipluation software uses fixed-point math for matrix
math. However, in my PowerPC port, I am getting hardly no
performance boost (seems slower to me) when I hit the matrix
calcuations.

After running TrapsCheck (very cool stuff), I find that the Fixed
point math routines are not native. Ugh.

After deciding not to do floating point because of speed, finding
that Fixed-point calculations are slower now is not too funny.
I would like to keep it using fixed point so that I can get good
performance regardless of processor.

Any ideas aobut how to get around this? Any ideas when the Fixed
point routines  will be native?

Any separate libraries to do fixed point calculations?

- -----------------------------------------------------------------
Willie Rauchwerger         AppleLink: Willie
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Wed, 6 Apr 1994 22:50:44 GMT
Organization: Adobe Systems Incorporated

Willie Rauchwerger <[e-mail]> writes
> My image manipluation software uses fixed-point math for matrix
> math. However, in my PowerPC port, I am getting hardly no
> performance boost (seems slower to me) when I hit the matrix
> calcuations.
>
> After running TrapsCheck (very cool stuff), I find that the Fixed
> point math routines are not native. Ugh.

Fixed point routines are not handled via traps for native code. Rather they
are in the shared library InterfaceLib. This is a godd idea as already in
68K land people were using skanky hacks to get around the trap dispatcher
overhead for the fixed-point math code.

For emulated code, the cost of doing a mixed mode switch to native mode
outweighs the benefit of faster antive mode execution. (Especially since the
emualtor is going to be executing native multiply instructions anyway at the
bottom level.)
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Wed, 6 Apr 1994 23:46:17 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, [e-mail] (Zalman Stern) writes:
>Willie Rauchwerger <[e-mail]> writes
>>
>> My image manipluation software uses fixed-point math for matrix
>> math. However, in my PowerPC port, I am getting hardly no
>> performance boost (seems slower to me) when I hit the matrix
>> calcuations.
>
>For emulated code, the cost of doing a mixed mode switch to native mode
>outweighs the benefit of faster native mode execution. (Especially since the
>emualtor is going to be executing native multiply instructions anyway at the
>bottom level.)

Is fixed-point still going to be faster on the PowerPC than floating-
point?  It may not, since the PPC's floating-point unit is so much
faster than (say) the MC6888x's.  If someone could come up with some
hard figures for this, it'd be handy.  Zalman?  Anyone?

(I *think* I remember hearing that for most things - like, anything
more complex than loop counting and such - floating-point is going to
be faster on the PPC than integer math.  Am I right, or hallucinating
again?)

- -------------------------------------------------------------------
Christopher Tate             |   "Blue ice cubes?  How degenerate!"
MSD, Inc.                    |
[e-mail]    |    < anybody recognize the source? >

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 06 Apr 1994 18:24:34 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Chris Gonna' Find Ray Charles Tate) wrote:

> Is fixed-point still going to be faster on the PowerPC than floating-
> point?  It may not, since the PPC's floating-point unit is so much
> faster than (say) the MC6888x's.  If someone could come up with some
> hard figures for this, it'd be handy.  Zalman?  Anyone?
>
> (I *think* I remember hearing that for most things - like, anything
> more complex than loop counting and such - floating-point is going to
> be faster on the PPC than integer math.  Am I right, or hallucinating
> again?)

It seems to me that working out the details is going to be tough, and
variable over time.  I *suspect* that switching *some* operations to
floating point will speed things up, just because the processor can do more
things at once that way.  IF you're looking at code which has had
instruction scheduling applied to it, and IF the compiler you are using
does a good job of that (that's the part likely to vary over time).

Bottom line:  beware the quick and dirty "benchmark" in this area.  For
now, write your code in the most convenient (for
writing/understanding/maintenance) way.  [There was a flap a while back
about one of the compilers not strength-reducing loops over arrays from
multiplies to adds.  My particular quick and dirty "benchmark" (not to be
trusted) suggested that on PPC it makes no difference (so why should the
compiler bother, except to avoid folks complaining about "poor
optimization").]
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Thu, 7 Apr 1994 16:35:02 GMT
Organization: The World Public Access UNIX, Brookline, MA

[There was a flap a while back
about one of the compilers not strength-reducing loops over arrays from
multiplies to adds.  My particular quick and dirty "benchmark" (not to be
trusted) suggested that on PPC it makes no difference (so why should the
compiler bother, except to avoid folks complaining about "poor
optimization").]

Floating-point adds take about the same time as multiplies (1 more cycle
unless it is single-precision). Integer adds are -considerably- quicker
than integer multiples: 1 cycle vs. 5 or 9.

> Is fixed-point still going to be faster on the PowerPC than floating-
> point?

Again, it depends on the distribution of the operations. Integer
multiplies and divides are -way- slower than floating-point. Adds/subs
are -way- faster.

For any compiler that does instruction scheduling, you'll probably get
better results using floating-point, because the floating-point
arithmetic can operate in parallel with the integer instructions used for
loops, branches, etc.

-- John



+++++++++++++++++++++++++++

>From [e-mail]
Date: 8 Apr 94 01:19:50 MST
Organization: (none)

In article <2nv95q$[e-mail]>, Willie Rauchwerger <[e-mail]> writes:
> My image manipluation software uses fixed-point math for matrix
> math. However, in my PowerPC port, I am getting hardly no
> performance boost (seems slower to me) when I hit the matrix
> calcuations.
>
> After running TrapsCheck (very cool stuff), I find that the Fixed
> point math routines are not native. Ugh.
>
> After deciding not to do floating point because of speed, finding
> that Fixed-point calculations are slower now is not too funny.
> I would like to keep it using fixed point so that I can get good
> performance regardless of processor.
>
> Any ideas aobut how to get around this? Any ideas when the Fixed
> point routines  will be native?
>
> Any separate libraries to do fixed point calculations?
>
> -------------------------------------------------------------------
> Willie Rauchwerger         AppleLink: Willie
> Telemedicine Software Guy  Internet:  [e-mail]
> OU Health Sciences Center

Since you are claiming a need for critical speed, I wonder why you bother with
the overhead of the Fixed-Point trap  on the 68K side anyways?

Rolling your own 68k fixedpoint routines will save you 100+ CPU cycles for
every fixed-point call as that is the overhead of the trap dispatcher.

As I understand it, there is no trap dispatcher on the PowerMac: the emulator
does it automatically. However, that don't mean that you should be happy with
the result either way.

Having read this thread backwards, I note that the PowerMac doesn't do native
fixed point due to the overhead from the Mixed Mode manager. Why not roll your
own routines for both 68K and PowerMac and use each as it is appropriate,
thereby avoiding the trap dispatcher on the 68k Macs and the emulator overhead
on the PowerMacs?


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 8 Apr 1994 09:58:42 GMT
Organization: The Royal Institute of Technology

>fixed point due to the overhead from the Mixed Mode manager. Why not roll your
>own routines for both 68K and PowerMac and use each as it is appropriate,
>thereby avoiding the trap dispatcher on the 68k Macs and the emulator overhead
>on the PowerMacs?

Why not define macros for your data representation and manipulation,
and have it use single-precision floats on the PPC and fixeds on 68K?
That way, you get the superior math performance on the PPC (where
float multiplies/divides are faster than integer) and keep the speed
on the 68K. And, yes, implementing your own fixed math macros is
pretty much a must.
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   This article printed on 100% recycled electrons.

+++++++++++++++++++++++++++

>From Willie Rauchwerger <[e-mail]>
Date: 8 Apr 1994 14:42:46 GMT
Organization: OU Health Sciences Center

In article <2o39si$[e-mail]> Jon W!tte, [e-mail]
writes:
>Why not define macros for your data representation and manipulation,
>and have it use single-precision floats on the PPC and fixeds on 68K?
>That way, you get the superior math performance on the PPC (where
>float multiplies/divides are faster than integer) and keep the speed
>on the 68K. And, yes, implementing your own fixed math macros is
>pretty much a must.

OK. It is obvious to me that I need to roll my own fixed point routines.
My question is whether there are any out there right now that people
have used to get around the trap overhead, or do I really need to roll
my own. (I think I can handle most of it, but I worry about it being
entirrly correct, and those trig functions...)

My next question is, how can floating point be faster than integer
math on the PowerPC (or any processor for that matter)? It would
seem to me that no matter how fast fp is, integer should faster -
otherwise, should I start using fp for counters, etc. :-)

- -----------------------------------------------------------------
Willie Rauchwerger         AppleLink: Willie
Telemedicine Software Guy  Internet:  [e-mail]
OU Health Sciences Center

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 8 Apr 1994 15:40:13 GMT
Organization: The Royal Institute of Technology

In <2o3qh6$[e-mail]> Willie Rauchwerger <[e-mail]> writes:

>My next question is, how can floating point be faster than integer
>math on the PowerPC (or any processor for that matter)? It would
>seem to me that no matter how fast fp is, integer should faster -
>otherwise, should I start using fp for counters, etc. :-)

The integer unit is not designed the same as the floating-point
unit, and the FP unit kicks some serious butt.

The only thing preventing you from using floating point registers
for counters is that you can't index using floating-point registers,
and the conversion to integer is slow. Else, go ahead! (addition
and subtraction of course aren't faster in FP, but multiply and
divide are)

Cheers,

                    / h+
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
 "If people bought cars according to the same principles they buy computers,
  cars would behave like Lamborghinis but would be built and look like Yugos."
                     -- Craig Fields

+++++++++++++++++++++++++++

>From [e-mail] (Robert Cassidy)
Date: Fri, 08 Apr 1994 09:45:15 -0700
Organization: TLG Project

In article <2o3tst$[e-mail]>, [e-mail] (Jon Wtte)
wrote:

> In <2o3qh6$[e-mail]> Willie Rauchwerger <[e-mail]> writes:
>
> >My next question is, how can floating point be faster than integer
> >math on the PowerPC (or any processor for that matter)? It would
> >seem to me that no matter how fast fp is, integer should faster -
> >otherwise, should I start using fp for counters, etc. :-)
>
> The integer unit is not designed the same as the floating-point
> unit, and the FP unit kicks some serious butt.
>
> The only thing preventing you from using floating point registers
> for counters is that you can't index using floating-point registers,
> and the conversion to integer is slow. Else, go ahead! (addition
> and subtraction of course aren't faster in FP, but multiply and
> divide are)

Doesn't the integer unit handle all of the register loading as well?
Wouldn't that be even more incentive to use the fp unit in certain
instances?

--
Robert Cassidy
TLG Project
UC Irvine

Let's hope 'Information SuperTollroad' isn't the catchphrase of the next
decade...

+++++++++++++++++++++++++++

>From [e-mail] (Chris Forden)
Date: Fri, 8 Apr 1994 16:57:41 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Excerpted from my upcoming article in the May issue of
MacTech--

Clever programmers of 68K Macs have done the fastest
calculations with integer arithmetic.  For instance, the
calculation of screen position of 2D CAD objects can be done
quickest using the long (32 bit) integer arithmetic available
on the 68020 and better.  (The FixMath routines in those
machines’s ROM automatically make use of the extended
instructions.)  Some programmers were even willing to put up
the aggravation of doing all the worst-case analyses of
overflow and underflow needed to use fixed-point math routines
reliably.

However, on the PowerPC, the floating point performance is so
much improved that now one gets faster execution by using
floating point routines than by using fixed point arithmetic in
any case where precautions would need to be taken against
overflow error or precision loss due to underflow.  Those two
enemies of integer arithmetic–  overflow and underflow–  ravage
more fixed point math schemes than programmers expect a priori.
 Therefore calculating with floating point is generally much
easier than adapting fixed-point arithmetic to one’s needs.

So how much faster is floating point?  A friend of mine timed
various implementations of an FFT-based image processing
algorithm running on several Mac platforms.  Here are his
results tabularized, including single precision floating point,
for  a one-way 512 x 512 FFT:

             IIci w/cache       Power Mac proto
             ------------       ---------------
integer      52 sec             14.5 sec
single float 80 sec             3   sec

Integer arithmetic on the Power Mac prototype was about the
same as the Quadra 840av’s, but single precision float on the
Power Mac was 4.5 times faster than the faster (integer with
special long mul assembly) arithmetic on Q840av.  We were using
a bottom-of-the-line Power Mac prototype, running at only 50
MHz.

Double-precision floating point on the PowerPC is only 0% to 20%
slower than single-precision floating point.  The 64 bits of
the double-precision format mean you have great freedom from
precision loss.  The PowerPC also has a multiply-and-add
instruction, often called “multiply and accumulate”.  It
combines a multiplication and an addition into a single
instruction.  Many signal processing programs for audio or
images can make heavy use of that instruction, which optimizing
--
[e-mail] 's self-referential signature quote:  "Huh?"

+++++++++++++++++++++++++++

>From [e-mail]
Date: 9 Apr 94 16:30:50 MST
Organization: (none)

In article <2o3qh6$[e-mail]>, Willie Rauchwerger <[e-mail]> writes:
> In article <2o39si$[e-mail]> Jon W!tte, [e-mail]
> writes:
>>Why not define macros for your data representation and manipulation,
>>and have it use single-precision floats on the PPC and fixeds on 68K?
>>That way, you get the superior math performance on the PPC (where
>>float multiplies/divides are faster than integer) and keep the speed
>>on the 68K. And, yes, implementing your own fixed math macros is
>>pretty much a must.
>
> OK. It is obvious to me that I need to roll my own fixed point routines.
> My question is whether there are any out there right now that people
> have used to get around the trap overhead, or do I really need to roll
> my own. (I think I can handle most of it, but I worry about it being
> entirrly correct, and those trig functions...)
>
> My next question is, how can floating point be faster than integer
> math on the PowerPC (or any processor for that matter)? It would
> seem to me that no matter how fast fp is, integer should faster -
> otherwise, should I start using fp for counters, etc. :-)
>
FP adds and subtracts are every bit as fast as fixed point adds and subtracts.
In fact, I understand that it is possible to get extra speed out of the 601 by
using fp indexes in loops...

Lawson

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Thu, 14 Apr 1994 01:14:02 -0700
Organization: Internet for the Olympic Peninsula

In article <2nv95q$[e-mail]>, Willie Rauchwerger
<[e-mail]> wrote:

> After deciding not to do floating point because of speed...

A preconception which has long been true, on a wide variety of hardware.
But...you may well find that using float (the 4-byte form) on PPC is the
right way to go.  Run your time trials on your program built that way (and
let us know how they come out).  [Enabling the Instruction Scheduling
optimization could well be important here.  If you're using a compiler
which does it well or even semi-well.]

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Fri, 15 Apr 1994 16:30:31 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> ,
[e-mail] writes:
>Having read this thread backwards, I note that the PowerMac doesn't do
native
>fixed point due to the overhead from the Mixed Mode manager. Why not
roll your
>own routines for both 68K and PowerMac and use each as it is appropriate,
>thereby avoiding the trap dispatcher on the 68k Macs and the emulator
overhead
>on the PowerMacs?

Many of the FixMath routines are "split" traps, which do not support
patching
anymore. On PowerPC, they are implemented inside InterfaceLib directly,
and
are not called through the trap dispatcher...

-Dave Falkenburg
-Apple Computer, Inc.

+++++++++++++++++++++++++++

>From [e-mail]
Date: 17 Apr 94 08:09:19 MST
Organization: (none)

In article <[e-mail]>, Dave Falkenburg <[e-mail]> writes:
> In article <[e-mail]> ,
> [e-mail] writes:
>>Having read this thread backwards, I note that the PowerMac doesn't do
> native
>>fixed point due to the overhead from the Mixed Mode manager. Why not
> roll your
>>own routines for both 68K and PowerMac and use each as it is appropriate,
>>thereby avoiding the trap dispatcher on the 68k Macs and the emulator
> overhead
>>on the PowerMacs?
>
> Many of the FixMath routines are "split" traps, which do not support
> patching
> anymore. On PowerPC, they are implemented inside InterfaceLib directly,
> and
> are not called through the trap dispatcher...
>
> -Dave Falkenburg
> -Apple Computer, Inc.

I take it that they are "native" then?


Lawson

---------------------------

>From [e-mail] (-= Godfather Moof =-)
Subject: Keeping DialogPtr's in RAM after startup...
Date: 13 Apr 1994 23:44:59 GMT
Organization: CS Outreach Services, Oregon State University, Corvallis, OR, USA

I'm writing an INIT that I would like to load a DialogPtr into ram at
startup so that the trap macro I am patching can use it later.  So far
I've tryed converting the ptr to a handle and locking the handle, but without
success.  I've tryed just opening up the file the Dialog Box is located in,
but that's to much of a hassle in case the dialog resource gets deleted,
(which it might).

Can anyone help?



                                                                   /-/
             Dogcow lives...                                   ___/ /__
                                                              /__  ___/
             Godfather Moof:                                  | / /| |
             [e-mail]                              |/_/ | |
                                                              | |  | |
             He'll make you an offer you can't refuse.        | |    |
                                                                |

+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Thu, 14 Apr 1994 20:41:09 GMT
Organization: Datawatch Corporation

In article <2oi05r$[e-mail]>, [e-mail] (-=
Godfather Moof =-) wrote:

> I'm writing an INIT that I would like to load a DialogPtr into ram at
> startup so that the trap macro I am patching can use it later.  So far
> I've tryed converting the ptr to a handle and locking the handle, but without
> success.  I've tryed just opening up the file the Dialog Box is located in,
> but that's to much of a hassle in case the dialog resource gets deleted,
> (which it might).
>

Forget abou it. Simply (at INIT time) call the following routine (passing
CurResFile() as the refNum) to learn where your INIT is. Then, in your
patch, when you need access to your resources, simply open the INIT file
and use the resources. Don't forget to close it when you are done.

OSErr FindFileSpec(short refNum, short *foundVRefNum, long *foundDirID,
unsigned char *fileName)
{
    FCBPBRec        pb;
    OSErr           err = noErr;

    pb.ioCompletion = NULL;
    pb.ioNamePtr = fileName;
    pb.ioVRefNum = 0;
    pb.ioRefNum = refNum;
    pb.ioFCBIndx = 0;

    err = PBGetFCBInfoSync(&pb);

    *foundVRefNum = pb.ioFCBVRefNum;
    *foundDirID = pb.ioFCBParID;

    return err;
}

___________________________________________________________
_/_/_/_/   Joe Zobkiw                                   ,,,
    _/     Senior Software Engineer                     - -
  _/       Datawatch Corporation                         L
_/_/_/_/   [e-mail]                          -

+++++++++++++++++++++++++++

>From [e-mail] (Peter Mattis)
Date: 16 Apr 1994 23:29:00 GMT
Organization: Computer Science Undergrad Assoc., UCBerkeley

In article <[e-mail]>,
joe zobkiw <[e-mail]> wrote:
>In article <2oi05r$[e-mail]>, [e-mail] (-=
>Godfather Moof =-) wrote:
>
>> I'm writing an INIT that I would like to load a DialogPtr into ram at
>> startup so that the trap macro I am patching can use it later.  So far
>> I've tryed converting the ptr to a handle and locking the handle, but without
>> success.  I've tryed just opening up the file the Dialog Box is located in,
>> but that's to much of a hassle in case the dialog resource gets deleted,
>> (which it might).
>>
>
>Forget abou it. Simply (at INIT time) call the following routine (passing
>CurResFile() as the refNum) to learn where your INIT is. Then, in your
>patch, when you need access to your resources, simply open the INIT file
>and use the resources. Don't forget to close it when you are done.
[SNIP]

Yes, but what happens if the user moves the init file? (Hmm...bit of a
problem, isn't it?)

The method I used for displaying a dialog box in the manner you
describe is to get the handle to the 'DITL' (dialog items list) resource
at start time. Remember to call DetachResource and HLock the handle.
This handle can then be used in a call to NewDialog to create a dialog
with the your items in it.

Be careful and make sure the item list doesn't get deleted somewhere
along the line.

-Peter Mattis

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Sun, 17 Apr 1994 03:22:03 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <2opsbs$[e-mail]>,
Peter Mattis <[e-mail]> wrote:
>
>The method I used for displaying a dialog box in the manner you
>describe is to get the handle to the 'DITL' (dialog items list) resource
>at start time. Remember to call DetachResource and HLock the handle.
>This handle can then be used in a call to NewDialog to create a dialog
>with the your items in it.
>
>Be careful and make sure the item list doesn't get deleted somewhere
>along the line.

You would also have to ensure that the dialog only accesses resources
from the system file. For instance, you couldn't specify a popup
control using 'CNTL' and 'MENU' resources. You could write code to
create the popup menu on the fly, or you could write code to create
the control and menu by saving copies of the resources, and then
attach the popup to the dialog. It's easier, as suggested in a prior
post, just to open the extension's resource file before creating the
dialog. I don't think it's too unreasonable to expect an extension to
be able to find its own file or some preferences file. If the user
goes and moves the file, a simple alert (or notification manager
alert) could issue a gentle admonishment.
--
Ari Halberstadt    [e-mail]     #include <std/disclaimer.h>
"These beetles were long considered to be very rare because very few
entomologists look for beetles in the mountains, in winter, at night,
during snow storms." -- Purves W. K., et al, "Life: The Science of

---------------------------

>From Robert Hess <[e-mail]>
Subject: Metrowerks News from MacWEEK
Date: Sat, 9 Apr 1994 02:35:44 GMT
Organization: MacWEEK

As a service, here are some snippets from Monday!s MacWEEK. I'll try to do
this in the future when there's developer-related news but it will be as
time permits...

St. Laurent, Quebec -- Metrowerks Inc., the developer community's bold new
kid on the block, has received a big boost from a formidable ally, IBM
Corp., and will announce several major additions to its CodeWarrior
product this week.

Metrowerks has formed an agreement with IBM which gives Metrowerks access
to Big Blue's compiler optimization technology for current and future
PowerPC processors. As a result, Mac developers will have access to the
best PowerPC code generators available, said Jean Belanger, Metrowerks'
chairman. "In addition to having the fastest compiler, we'll be able to
generate the fastest code," he said.

At Apple's Worldwide Developers Conference next month Metrowerks will
ship:

MPW MW CW: Metrowerks will make its native and 680x0 compilers available
to users of Apple's Macintosh Programmer's Workshop. The combination will
bring CodeWarrior's speed and MPW's large project- and team-management
tools together.

Native-hosted 68K codegen: Metrowerks President and CEO Greg Galanos said,
"The new compiler is four to five times as fast as our 680x0-based
compiler and eight times as fast as Think."

Metrowerks will ship its 680x0 and PowerPC compilers as fat binaries, so
both can run and generate code for either processor line. The MPW-hosted
compiler will be included free.

Since developers feel Apple has not committed to continue supporting the
language,  Metrowerks will introduce an Object Pascal version of its
compiler by year-end.

Metrowerks is now bundling CodeWarrior with NeoLogic Systems' NeoPersist,
an object-oriented data storage utility for programmers. An encrypted copy
of NeoAccess, an object-oriented database extension of NeoPersist, is also
included; users can upgrade for $649.

Metrowerks plans to open its first U.S. office in Austin, Texas, June 1.
The Austin office will be the headquarters of the technical support,
quality assurance and sales divisions.

[For the full text, see MacWEEK or ZiffNet on CompuServe, eWorld or
AppleLink]

========================================================================
Robert Hess, WEEKgeek                      [e-mail]
MacWEEK                                    AppleLink: WNDZSX
301 Howard                                 CompuServe: 72511,333
San Francisco, Calif. 94105                America Online: MacWEEK
[phone] days                        MCI: RHESS
[phone] fax
[phone] nights                      I speak for myself.
now doesn!t that make you feel better?     And sometimes not even that.
========================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Geweke)
Date: Sat,  9 Apr 1994 01:08:09 -0400
Organization: Michigan State University

In article <[e-mail]>, Robert Hess
<[e-mail]> writes:
> As a service, here are some snippets from Monday!s MacWEEK. I'll try to
> do this in the future when there's developer-related news but it will
> be as time permits...

Thank you very much for this! There are obviously lots of people who still
can't really get MacWEEK.

> St. Laurent, Quebec -- Metrowerks Inc., the developer community's bold
> new kid on the block, has received a big boost from a formidable ally,
> IBM Corp., and will announce several major additions to its CodeWarrior
> product this week.
>
> Metrowerks has formed an agreement with IBM which gives Metrowerks
> access to Big Blue's compiler optimization technology for current and
> future PowerPC processors. As a result, Mac developers will have access
> to the best PowerPC code generators available, said Jean Belanger,
> Metrowerks' chairman. "In addition to having the fastest compiler, we'
> ll be able to generate the fastest code," he said.

Am I the only one saying Wow? I've heard only huge rave reviews about IBM's
compilers, but figured they were only available with the Macintosh on RISC
SDK. Great!





+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Sat, 9 Apr 94 09:34:08 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), Robert Hess <[e-mail]> writes:

> Metrowerks will ship its 680x0 and PowerPC compilers as fat binaries, so
> both can run and generate code for either processor line. The MPW-hosted
> compiler will be included free.

Will this apply retrospectively to those of us who bought DR1 (2,3..)?
Or do I have to buy the MPW-hosted compiler separately? If the latter, where
do I get it from?


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Sat, 9 Apr 1994 08:41:27 GMT
Organization: Adobe Systems Incorporated

Andrew Geweke writes
> Am I the only one saying Wow? I've heard only huge rave reviews about
IBM's
> compilers, but figured they were only available with the Macintosh on RISC
> SDK. Great!

IBM's compilers are *not* on the Macintosh on RISC SDK. They are only
available for IBM's AIX operating system.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
"Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins)

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Sat, 9 Apr 1994 09:03:06 GMT
Organization: The World Public Access UNIX, Brookline, MA

> Metrowerks has formed an agreement with IBM which gives Metrowerks
> access to Big Blue's compiler optimization technology for current and
> future PowerPC processors. As a result, Mac developers will have access
> to the best PowerPC code generators available, said Jean Belanger,
> Metrowerks' chairman. "In addition to having the fastest compiler, we'
> ll be able to generate the fastest code," he said.

So that the rumours don't fly to far too fast on this one, let me clarify
the situation as it will affect you, the users.

We have an agreement which says that as I develop the next version
of our PowerPC code generator, I'm free to ask for advice, experiences,
etc. from some of the guys at IBM's Watson Research Center where the
POWER architecture was originally designed. It turns out much of my
current code generator design is already based on some papers that they
wrote at Watson anyway. They are willing to be pretty free with their
experience, but I imagine they will also keep some tricks to themselves.

No source code is involved, at least not to my knowledge. The important
point is that Metrowerks is going to invest pretty much 100% of my time
developing aggressive global optimization for future versions of our
product. How closely we compare with IBMs xlc compilers depends mostly on
how good a job I do at that. Our agreement with IBM is an offshoot of a
relationship we have with some great guys in IBM Microelectronics, who
want to see the PowerPC chip succeed and see Apple's broad market
penetration with a low-cost desktop PowerPC as crucial to their success.

By the way, although IBM seems to have a real stuffed-shirt image, Watson
Research seems like a cool place. People there look just like us! Also,
it was cool to sit in the office of a guy who wrote probably the first
paper on Common Subexpression Elimination in a compiler.

In my early years at Symantec we always wrestled with the "THINK for fast
compiles, MPW for production code" image, one that Apple liked to
propagate, until we got serious in v5.0 and wrote a real code
generator. I don't want Metrowerks to be pigeonholed like that. For DR3
and probably DR4, we will be the "fast" compiler which makes some
concessions in the optimization area. (This has not stopped a large
number of commercial developers of well-known products from using
CodeWarrior to "go native")

After that, we intend to generate code as good as anybody else's.

-- John McEnerney, Metrowerks PowerPC Product Architect

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 9 Apr 1994 12:30:13 GMT
Organization: The Royal Institute of Technology

In <[e-mail]> [e-mail] (Andrew Geweke) writes:

>Am I the only one saying Wow? I've heard only huge rave reviews about IBM's
>compilers, but figured they were only available with the Macintosh on RISC
>SDK. Great!

Nope, the Macintosh on RISC SDK uses the Lucid compiler, PPCC.
To use xlc, you have to have an IBM RS/6000 with the development
environment, figure on spending $15000 and upwards...



--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

  Clearly, most humans are not rational beings; they are rationalizing beings.
                     -- Mel Walker

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Sun, 10 Apr 1994 04:24:59 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Sak Wathanasin) writes:

>> Metrowerks will ship its 680x0 and PowerPC compilers as fat binaries, so
>> both can run and generate code for either processor line. The MPW-hosted
>> compiler will be included free.

>Will this apply retrospectively to those of us who bought DR1 (2,3..)?
>Or do I have to buy the MPW-hosted compiler separately? If the latter, where
>do I get it from?

We'll just tack these onto the CD for DR3, DR4, etc. You'll ghet them
automatically (as long as you regstered!)

-- John McEnerney, Metrowerks PowerPC Product Architect


+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Mon, 11 Apr 94 00:24:40 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John McEnerney) writes:
> >Will this apply retrospectively to those of us who bought DR1 (2,3..)?
> >Or do I have to buy the MPW-hosted compiler separately? If the latter, where
> >do I get it from?
>
> We'll just tack these onto the CD for DR3, DR4, etc. You'll ghet them
> automatically (as long as you regstered!)

Do we have to wait for DR3 for the MPW-hosted compiler? I thought the press
release said that it would be released at the WWDC. I'd be happy to buy a
separate copy of the MPW-hosted compiler if it were available...


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Mon, 11 Apr 1994 07:03:19 GMT
Organization: The World Public Access UNIX, Brookline, MA

>Do we have to wait for DR3 for the MPW-hosted compiler? I thought the press
>release said that it would be released at the WWDC. I'd be happy to buy a
>separate copy of the MPW-hosted compiler if it were available...

DR3 is the version which we will be shipping at the WWDC! Of course,
since we will probably get it in the mail just as we ourselves are
leaving for WWDC, you might not get yours until after the WWDC depending
on shipping time etc.

-- John McEnerney, Metrowerks PowerPC Product Architect

+++++++++++++++++++++++++++

>From Robert Hess <[e-mail]>
Date: Mon, 11 Apr 1994 16:44:35 GMT
Organization: MacWEEK

In article <[e-mail]> Andrew Geweke, [e-mail]
writes:
>Thank you very much for this! There are obviously lots of people who still
>can't really get MacWEEK.

Well, keep in mind:

a) My employer won't let me post the full article;
b) This is going be as time permits.

So you're still better off getting the full scoop via MacWEEK or online.

========================================================================
Robert Hess, WEEKgeek                      [e-mail]
MacWEEK                                    AppleLink: WNDZSX
301 Howard                                 CompuServe: 72511,333
San Francisco, Calif. 94105                America Online: MacWEEK
[phone] days                        MCI: RHESS
[phone] fax
[phone] nights                      I speak for myself.
now doesn!t that make you feel better?     And sometimes not even that.
========================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Sun, 10 Apr 1994 12:27:59 +0800
Organization: NCRPDA, Curtin University

>Since developers feel Apple has not committed to continue supporting the
>language,  Metrowerks will introduce an Object Pascal version of its
>compiler by year-end.

And there was much rejoicing!  Now, what was the upgrade strategy for
this?  If the upgrade from Pascal to Object Pascel is sufficiently cheap,
then I'd love to buy a copy now and help get the bugs out!
   Peter.
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sun, 17 Apr 1994 04:22:07 GMT
Organization: cellular

[e-mail] (Peter N Lewis) writes:

>>Since developers feel Apple has not committed to continue supporting the
>>language,  Metrowerks will introduce an Object Pascal version of its
>>compiler by year-end.

>And there was much rejoicing!  Now, what was the upgrade strategy for
>this?  If the upgrade from Pascal to Object Pascel is sufficiently cheap,
>then I'd love to buy a copy now and help get the bugs out!

Since the license for DR2 includes updates through DR5 or so, and since
DR5 isn't supposed to ship this year, and since Object Pascal *is*
supposed to ship this year, my guess is that buying CodeWarrior now is
sufficient. Metrowerks may not have thought along this precise path, so
when you call them to confirm, mention it.
--
 Pete Gontier, CTO, Integer Poet Software; [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 17 Apr 1994 16:24:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, [e-mail] (Pete Gontier)
writes:
>> Since the license for DR2 includes updates through DR5 or so, and since
DR5 isn't supposed to ship this year, and since Object Pascal *is*
supposed to ship this year, my guess is that buying CodeWarrior now is
sufficient.

Right, Every CD will include the latest compiler versions available.  With more
source codes and 3rd party demos and tools.  If you purchase the DR\2
pre-release version you will receive DR\3. DR\4, DR\5 as well, these CD's will
come out every 4 months.

The only upgrading necessary could be from a Bronze to a Gold if you needed to
write for a PowerPC later on.

Ron Liechty
[e-mail]
Metrowerks Inc.

---------------------------

>From [e-mail] (Dale M. Greer)
Subject: WaitNextEvent Emulated on PoMac!?
Date: 11 Apr 1994 15:50:35 GMT
Organization: The University of Texas at Dallas

Someone on the CodeWarrior mailing list said that WaitNextEvent runs
in emulation mode on the Power Macintosh.  This was in response to
a programmer frustrated by jerky animation on the Power Mac.  It was
recommended that he put code to call WaitNextEvent after some number of
passes through the event loop, say every tenth pass.

It seems like WaitNextEvent would be one of the most frequently used
routines by most applications, so why didn't Apple make it native?  Will
it be native for System 7.5?

--

Dale Greer, [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Chris Gonna' Find Ray Charles Tate)
Date: Mon, 11 Apr 1994 16:34:10 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <2obrkb$[e-mail]>, [e-mail] (Dale M. Greer) writes:
>
>Someone on the CodeWarrior mailing list said that WaitNextEvent runs
>in emulation mode on the Power Macintosh.  This was in response to
>a programmer frustrated by jerky animation on the Power Mac.  It was
>recommended that he put code to call WaitNextEvent after some number of
>passes through the event loop, say every tenth pass.
>
>It seems like WaitNextEvent would be one of the most frequently used
>routines by most applications, so why didn't Apple make it native?  Will
>it be native for System 7.5?

I expect it's *because* it's one of the most-called routines.  If it were
native, then *every time* an emulated application called it would entail
at least two mode switches (into native to run the trap, then back out
again to run the application).  Mode switching is expensive.

Now, it *could* be that the trap is run native when you're running in
native mode, but emulated when you're running under the emulator; it seems
to me this would be optimal.  Does anyone know whether this is indeed the
case under the current PowerMac system software?

- -------------------------------------------------------------------
Christopher Tate             |   "Blue ice cubes?  How degenerate!"
MSD, Inc.                    |
[e-mail]    |    < anybody recognize the source? >

+++++++++++++++++++++++++++

>From Erik Schwiebert <[e-mail]>
Date: 11 Apr 1994 18:12:43 GMT
Organization: Cornell University

In article <[e-mail]> Chris Gonna' Find Ray
Charles Tate, [e-mail] writes:
>In article <2obrkb$[e-mail]>, [e-mail] (Dale M.
Greer) writes:
>>
>>Someone on the CodeWarrior mailing list said that WaitNextEvent runs
>>in emulation mode on the Power Macintosh.  This was in response to
>>a programmer frustrated by jerky animation on the Power Mac.  It was
>>recommended that he put code to call WaitNextEvent after some number of
>>passes through the event loop, say every tenth pass.
>>
>>It seems like WaitNextEvent would be one of the most frequently used
>>routines by most applications, so why didn't Apple make it native?
Will
>>it be native for System 7.5?
>
>I expect it's *because* it's one of the most-called routines.  If it were
>native, then *every time* an emulated application called it would entail
>at least two mode switches (into native to run the trap, then back out
>again to run the application).  Mode switching is expensive.
>
>Now, it *could* be that the trap is run native when you're running in
>native mode, but emulated when you're running under the emulator; it
seems
>to me this would be optimal.  Does anyone know whether this is indeed the
>case under the current PowerMac system software?

well, according to the example in New Inside Mac: PowerPC Software (or
whatever the title is), Apple gives an example that shows exactly what
Dale Greer said.  ie, the code only calls WNE every once in a while.  I
dont have the book, but it looked something like this:

procedure mainloop;
 var theEvent:eventRecord;
begin
  if (tickCount - gTimeOfLastCall) > gTimeToWait then begin
    gotEvent := waitNextEvent(blah, blah, blah ...)
    gTimeOfLastCall := tickCount;
  else
    gotEvent := false;
  if gotEvent then
    case  whatever of whatever
  etc...
end;

anyways, you get the idea...  where gTimeToWait is 10 ticks or something
like that (getCaretTime maybe?)

- -----------------------------------------------------------------
 "So live that you can |------------------| "Life is a tragedy for
  look any man in the  | [e-mail] |  those who feel, and a
  eye and tell him     |------------------|  comedy for those who
  go to hell."         |     Erik V.      |  think."
  -- Anonymous         |   Schwiebert     |  -- Jean De La Bruyere
- -----------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 11 Apr 1994 11:01:28 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Chris Gonna' Find Ray Charles Tate) wrote:

> In article <2obrkb$[e-mail]>, [e-mail] (Dale M. Greer) writes:
> >
> >Someone on the CodeWarrior mailing list said that WaitNextEvent runs
> >in emulation mode on the Power Macintosh.  This was in response to
> >a programmer frustrated by jerky animation on the Power Mac.  It was
> >recommended that he put code to call WaitNextEvent after some number of
> >passes through the event loop, say every tenth pass.
> >
>
> I expect it's *because* it's one of the most-called routines.  If it were
> native, then *every time* an emulated application called it would entail
> at least two mode switches (into native to run the trap, then back out
> again to run the application).  Mode switching is expensive.
>
> Now, it *could* be that the trap is run native when you're running in
> native mode, but emulated when you're running under the emulator; it seems
> to me this would be optimal.  Does anyone know whether this is indeed the
> case under the current PowerMac system software?

It is possible to create "fat" traps...run 68K or PPC.  It was done for
several traps which **are unlikely to be patched**.  It's not clear that
existing apps which patch traps can deal with the fat ones.  Of course, no
one ever patches WaitNextEvent, and everyone who does so does it "right",
and will instantly retrofit "fat" patches.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Scott Barta)
Date: 11 Apr 1994 15:33:23 -0400
Organization: The Ohio State University

> well, according to the example in New Inside Mac: PowerPC Software (or
> whatever the title is), Apple gives an example that shows exactly what
> Dale Greer said.  ie, the code only calls WNE every once in a while.  I
> dont have the book, but it looked something like this:
>
    [code deleted]
> anyways, you get the idea...  where gTimeToWait is 10 ticks or something
> like that (getCaretTime maybe?)


There's one big problem with all of this.  While your application is
burning up cycles waiting to do its next WNE, it's _not_ giving up cycles
to other applications.  Very unfriendly.  I'm surprised that Apple is
advocating this, unless they're thinking ahead to some happy day when
applications will be able to preempt each other without WNE.  I would think
that you'd just want to call WNE as often as possible and grit your teeth
through the mode switches until the needed Toolbox calls go
native...shucks, your program may not be fully _debugged_ by then.  :-)


--
--Scott Barta
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Clark)
Date: Mon, 11 Apr 1994 16:33:16 -0500
Organization: Northwestern University

In article <[e-mail]>,
[e-mail] (Scott Barta) wrote:

> There's one big problem with all of this.  While your application is
> burning up cycles waiting to do its next WNE, it's _not_ giving up cycles
> to other applications.  Very unfriendly.  I'm surprised that Apple is
> advocating this, unless they're thinking ahead to some happy day when
> applications will be able to preempt each other without WNE.  I would think
> that you'd just want to call WNE as often as possible and grit your teeth
> through the mode switches until the needed Toolbox calls go
> native...shucks, your program may not be fully _debugged_ by then.  :-)


A recent develop had a question on this, I believe. Someone had a app that
did a calculation, called WNE, did another calc, etc. When translated to
native code, more time was being after yielding to other apps than to
perform calculations. The suggestion was to call WNE less often, based on
some fixed timing schedule, and not on how fast or slow a particular series
of calculations took. This seems to be perfectly defensible.

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Mon, 11 Apr 1994 21:53:59 GMT
Organization: The World Public Access UNIX, Brookline, MA

Erik Schwiebert <[e-mail]> writes:
>In article <[e-mail]> Chris Gonna' Find Ray
>Charles Tate, [e-mail] writes:
>>In article <2obrkb$[e-mail]>, [e-mail] (Dale M.
>Greer) writes:
>>>Someone on the CodeWarrior mailing list said that WaitNextEvent runs
>>>in emulation mode on the Power Macintosh.  This was in response to
>>>a programmer frustrated by jerky animation on the Power Mac.  It was
>>>recommended that he put code to call WaitNextEvent after some number of
>>>passes through the event loop, say every tenth pass.
>well, according to the example in New Inside Mac: PowerPC Software (or
>whatever the title is), Apple gives an example that shows exactly what
>Dale Greer said.  ie, the code only calls WNE every once in a while.  I
>dont have the book, but it looked something like this:
>procedure mainloop;
> var theEvent:eventRecord;
>begin
>  if (tickCount - gTimeOfLastCall) > gTimeToWait then begin
>    gotEvent := waitNextEvent(blah, blah, blah ...)
>    gTimeOfLastCall := tickCount;
>  else
>    gotEvent := false;
>  if gotEvent then
>    case  whatever of whatever
>  etc...
>end;

It's kind of nasty (since it hogs the machine while you do nothing, because
gotEvent is hard-set to false if WNE is not called). A big problem,
I see, is that GetOSEvent and OSEventAvail are emulated - a good
alternative would have been to use those to process events while in
the foreground (this makes your app hog the machine while it is in front,
but it's processing user interactions, not sitting in an idle loop like
the code above; of course, if you're not in the foreground you should
relinqueish the CPU ASAP).

I could easily see the rationale for WNE/GNE being emulated that the
likelihood of a Mixed Mode Switch when doing the process swap is
exceedingly high anyway (I think the device manager is still emulated,
and WNE calls SystemTask). But hogging the machine AND not responding
to user events strikes me as unnecessarily evil.

I do hope the event handling (OS Event Mgr, Toolbox, Device Mgr) goes fat
(not native, too many 68K emulated apps would suffer performance problems)
in the next release - would go a long way towards easing that problem.

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Dale M. Greer)
Date: 11 Apr 1994 22:24:03 GMT
Organization: The University of Texas at Dallas

Brian Clark ([e-mail]) wrote:
> In article <[e-mail]>,
> [e-mail] (Scott Barta) wrote:

> > There's one big problem with all of this.  While your application is
> > burning up cycles waiting to do its next WNE, it's _not_ giving up cycles
> > to other applications.  Very unfriendly.  I'm surprised that Apple is

> A recent develop had a question on this, I believe. Someone had a app that
> did a calculation, called WNE, did another calc, etc. When translated to
> native code, more time was being after yielding to other apps than to
> perform calculations. The suggestion was to call WNE less often, based on
> some fixed timing schedule, and not on how fast or slow a particular series
> of calculations took. This seems to be perfectly defensible.

Wouldn't it be nice if Apple had made a new GetMyPriority function, which
would get a value from a new resource which would tell your code how many
ticks to wait before calling WaitNextEvent.  Of course, the success of this
would depend on everyone using it, but if they did, then the user could set
priorities for each application as easily as setting the memory
requirements.  Theoretically. ;)

As an alternative to having the programmer provide the waiting logic,
why couldn't Apple have made a little piece of code to call GetMyPriority,
or something similar just before calling the emulated WaitNextEvent?  This
little piece of code could just return until its timer timed out, when
it would then act like a regular call to WaitNextEvent.

--

Dale Greer, [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Mon, 11 Apr 1994 22:46:20 GMT
Organization: Taligent, Inc.

In article <2obrkb$[e-mail]>, [e-mail] (Dale M.
Greer) wrote:

> Someone on the CodeWarrior mailing list said that WaitNextEvent runs
> in emulation mode on the Power Macintosh.  This was in response to

A good application will call WaitNextEvent with the appropriate sleep
value, which means it doesn't get called as often as you'd think.

> recommended that he put code to call WaitNextEvent after some number of
> passes through the event loop, say every tenth pass.

That might be appropriate for animation where you want to maintain control
as much as possible.  I don't think you'd want to do this based on number
of passes, but rather based on elapsed time as someone suggested.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Marcel Blonk)
Date: Tue, 12 Apr 1994 00:12:32 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Dale M. Greer ([e-mail]) wrote:
: It seems like WaitNextEvent would be one of the most frequently used
: routines by most applications, so why didn't Apple make it native?  Will
: it be native for System 7.5?

Most time spent in WNE, as seen from an app, is actually spent in the
other (background) apps that call WNE. Jerky animation and such, is caused
by other apps taking up too much time in the background (read: calling
WNE only every once in a while). The actual time spent in WNE itself is
negligible, therefore I can understand that apple doesn't make it a
priority to natify (from the verb 'to native') WNE (compare eg. the
average app spends 70% of it's time in DrawText)

mb


+++++++++++++++++++++++++++

>From [e-mail] (Steeeve)
Date: 12 Apr 1994 03:12:27 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <2obrkb$[e-mail]>, [e-mail] (Dale M. Greer)
writes:
>>>>
Someone on the CodeWarrior mailing list said that WaitNextEvent runs
in emulation mode on the Power Macintosh.
<<<<

I just finished up some code from which I expected to see a big speed gain on
the Power Mac, but it turned out to be slower than on a Quadra 800. I was
essentially doing this:

do some calculations;
fall through event loop;

I realized that in this case the only reasonable event was a mouse click, so I
changed it to

while( ! Button() )
   do some calculations;

flush any other events;  //so that the click is processed
fall through event loop;

Of course I probably should have done it like this in the first place, but on a
6100 it went from 190,000 calculations per hour to 1,475,000.


-Steve


+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: 12 Apr 1994 07:44:53 GMT
Organization: California Institute of Technology, Alumni Association

In article <[e-mail]>,
Scott Barta <[e-mail]> wrote:
>> well, according to the example in New Inside Mac: PowerPC Software (or
>> whatever the title is), Apple gives an example that shows exactly what
>> Dale Greer said.  ie, the code only calls WNE every once in a while.  I
>> dont have the book, but it looked something like this:
>>
>    [code deleted]
>> anyways, you get the idea...  where gTimeToWait is 10 ticks or something
>> like that (getCaretTime maybe?)
>
>
>There's one big problem with all of this.  While your application is
>burning up cycles waiting to do its next WNE, it's _not_ giving up cycles
>to other applications.  Very unfriendly.  I'm surprised that Apple is
>advocating this, unless they're thinking ahead to some happy day when
>applications will be able to preempt each other without WNE.  I would think
>that you'd just want to call WNE as often as possible and grit your teeth
>through the mode switches until the needed Toolbox calls go
>native...shucks, your program may not be fully _debugged_ by then.  :-)

Actually it turns out to be an extremely reasonable thing to do if you
want your application to get as much of the CPU as possible while yielding
in a way which feels very responsive to foreground applications.

If you make gTimeToWait 15 ticks, then when the user starts typing in the
foreground application he will be forced to wait no longer than 1/4
second before his application responds; for most applications users
won't feel a significant delay in the responsiveness of the application.
And since WNE won't return to the CPU-intensive application until there
is a delay in events arriving at the foreground application (such as when
the user pauses a second to think while typing in Microsoft Word),
the foreground application will get all the CPU needed to respond to the
user's typing or drawing.

I've used this technique in quite a few applications and have been
quite pleased at the amount of CPU my background CPU-intensive application
gets, while still getting reasonable responsiveness in the foreground
application.

                        - Bill

(Who isn't quite sure he understands why pre-emptive multi-tasking
is so hot, given how unresponsive a Sun workstation feels compared
to his less powerful Macintosh.)
--
 "A secret face--a touch of grace        William Edward Woody
  A man must learn to give a little space    [e-mail]
  A peaceful state--a submissive trait
  A man must learn to gently dominate" -- Rush, "Animate"

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 12 Apr 1994 08:44:59 GMT
Organization: The Royal Institute of Technology

In <2obrkb$[e-mail]> [e-mail] (Dale M. Greer) writes:

>It seems like WaitNextEvent would be one of the most frequently used
>routines by most applications, so why didn't Apple make it native?  Will
>it be native for System 7.5?

Wrong. WaitNextEvent isn't that important; when applications call it,
they expect some time to pass (since other apps can get switched in
during the call)

The real power suckers were DrawText() and FillRect() (==EraseRect())
plus a couple of others (the memory manager in some cases :-)
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --

   This article printed on 100% recycled electrons.

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 14 Apr 94 11:05:29
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Marcel Blonk) writes:
> Dale M. Greer ([e-mail]) wrote:
> : It seems like WaitNextEvent would be one of the most frequently used
> : routines by most applications, so why didn't Apple make it native?  Will
> : it be native for System 7.5?

> Most time spent in WNE, as seen from an app, is actually spent in the
> other (background) apps that call WNE.

This is true to a certain degree. However, excessive calling of WNE
*while the application still has something to do* may slow down your
code considerably.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
  "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes
   and weighs 30 tons, computers in the future may have only 1,000 vacuum
   tubes and weigh only 1 1/2 tons."         ---Popular Mechanics, March 1949



+++++++++++++++++++++++++++

>From [e-mail] (Marcel Blonk)
Date: Thu, 14 Apr 1994 19:05:26 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Matthias Neeracher ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail] (Marcel Blonk) writes:
: > Dale M. Greer ([e-mail]) wrote:
: > : It seems like WaitNextEvent would be one of the most frequently used
: > : routines by most applications, so why didn't Apple make it native?  Will
: > : it be native for System 7.5?

: > Most time spent in WNE, as seen from an app, is actually spent in the
: > other (background) apps that call WNE.

: This is true to a certain degree. However, excessive calling of WNE
: *while the application still has something to do* may slow down your
: code considerably.

True, but the issue here is, that to make the WNE code native, wouldn't
do much to improve performance. Not calling WNE too much has always been
an issue on the mac, way before the PowerMac.

mb

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Mon, 18 Apr 1994 20:07:43 GMT
Organization: Apple Computer

On any reasonably fast Mac it's a bad idea to call WNE too often; not that
the implentation itself is slow, but there are limitations in the OS on how
fast process switches can happen, so when you call WNE you should expect to
be gone for at least a tick or two if there are any other non-sleeping
processes on that machine.

Scott Barta, [e-mail] writes:
> There's one big problem with all of this.  While your application is
> burning up cycles waiting to do its next WNE, it's _not_ giving up cycles
> to other applications.  Very unfriendly.  I'm surprised that Apple is

Well they're not advocating calling it only once a minute! It's probably best
to call WNE about once a second max while you're in the foreground. If you're
in the background you may want to call it four times a second or so. If you
call WNE too often you're also giving up lots of cycles to a loop inside the
Process Manager that waits for TickCount to advance.

--Jens Alfke
  jens_alfke@powertalk              Rebel girl, rebel girl,
            .apple.com              Rebel girl you are the queen of my world

+++++++++++++++++++++++++++

>From Dave Falkenburg <[e-mail]>
Date: Mon, 18 Apr 1994 20:54:51 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]> Jens Alfke,
[e-mail] writes:
>Well they're not advocating calling it only once a minute! It's probably
best
>to call WNE about once a second max while you're in the foreground. If
you're
>in the background you may want to call it four times a second or so. If
you

You should ALWAYS dynamically calculate the sleep time!

When in the background, err on the side of calling WNE more than you'd
like with LARGE sleep values.

When running in the foreground, you should periodically call through, but
alter the frequency of your calling through if you are doing something
very compute-bound.

If you AREN'T compute bound, always call through... In most cases, the
worst thing this will do is pollute your instruction cache with other
people's code.

Of course, if you are doing something USER-bound (like a word processor)
you probably always want to call through anyway.


>call WNE too often you're also giving up lots of cycles to a loop inside
the
>Process Manager that waits for TickCount to advance.

Actually, I usually don't disagree with Jens, but this ONLY happens when
NO EVENTS are flying around and EVERY process is asleep...  In the
future, when we have a "real" operating system, we'll block instead...

-Dave Falkenburg
-Apple Computer, Inc.

---------------------------

>From Jeff DuMonthier <[e-mail]>
Subject: X2Fix code generation bug still in SC++ 7.0
Date: 6 Apr 1994 14:54:33 GMT
Organization: NASA GSFC

I recently posted sample code which demonstrated a code generation bug
in SC++ 6.0.1.  I have updated to 7.0 and the bug is still there, with
maybe a slight difference.  The following code demonstrates two
variations:

#include <fixmath.h>

Fixed FixIt1(extended x)
{
    Fixed f = X2Fix(x);           //< This works
    return f;
}

Fixed FixIt2(extended *x)
{
    Fixed f = X2Fix(*x);          //< This just fails.
    return f;
}

void main(void)
{
    extended x = 1.0;
    extended *xp = &x;

    Fixed f1 = FixIt1(x);
    Fixed f2 = FixIt2(&x);
    Fixed f3 = X2Fix(x);
    Fixed f4 = X2Fix(*xp);        //< Illegal instruction.
}

I started with a C++ project and used the factory default compilation
options for the project and for rebuilding the libraries.  The
following behavior is what I observed tracing through the program with
the source debugger:

FixIt1 works correctly and f1 will be assigned 0x00010000.  FixIt2 does
not work and f2 will be assigned 0 (local variable f in FixIt2 is also
assigned 0).  The assignment to f3 using X2Fix(x) works but
f4 = X2Fix(*xp) results in an illegal instruction error message (run
time, not a syntax error).

Here is the disassembled code:

FixIt1(long double):
00000000: 4E56 0000          LINK      A6,#$0000
00000004: 2F03               MOVE.L    D3,-(A7)
00000006: 594F               SUBQ.W    #$4,A7
00000008: 486E 0008          PEA       $0008(A6)
0000000C: A844               _X2Fix
0000000E: 201F               MOVE.L    (A7)+,D0
00000010: 2600               MOVE.L    D0,D3
00000012: 261F               MOVE.L    (A7)+,D3
00000014: 4E5E               UNLK      A6
00000016: 205F               MOVEA.L   (A7)+,A0
00000018: 4FEF 000A          LEA       $000A(A7),A7
0000001C: 4ED0               JMP       (A0)
0000001E

FixIt2(long double *):
00000000: 4E56 0000          LINK      A6,#$0000
00000004: 2F03               MOVE.L    D3,-(A7)
00000006: 594F               SUBQ.W    #$4,A7
00000008: 486E 0008          PEA       $0008(A6)
0000000C: A844               _X2Fix
0000000E: 201F               MOVE.L    (A7)+,D0
00000010: 2600               MOVE.L    D0,D3
00000012: 261F               MOVE.L    (A7)+,D3
00000014: 4E5E               UNLK      A6
00000016: 205F               MOVEA.L   (A7)+,A0
00000018: 584F               ADDQ.W    #$4,A7
0000001A: 4ED0               JMP       (A0)
0000001C

main:
00000000: 4E56 FFF4          LINK      A6,#$FFF4
00000004: 48E7 1E30          MOVEM.L   D3-D6/A2/A3,-(A7)
00000008: 2D7C 3FFF 8000     MOVE.L    #$3FFF8000,$FFF4(A6)
          FFF4
00000010: 42AE FFF8          CLR.L     $FFF8(A6)
00000014: 426E FFFC          CLR.W     $FFFC(A6)
00000018: 45EE FFF4          LEA       $FFF4(A6),A2
0000001C: 264A               MOVEA.L   A2,A3
0000001E: 41EE FFF4          LEA       $FFF4(A6),A0
00000022: 3F28 0008          MOVE.W    $0008(A0),-(A7)
00000026: 2F28 0004          MOVE.L    $0004(A0),-(A7)
0000002A: 2F10               MOVE.L    (A0),-(A7)
0000002C: 4EBA 0000          JSR       FixIt1(long double)
00000030: 2600               MOVE.L    D0,D3
00000032: 486E FFF4          PEA       $FFF4(A6)
00000036: 4EBA 0000          JSR       FixIt2(long double *)
0000003A: 2800               MOVE.L    D0,D4
0000003C: 594F               SUBQ.W    #$4,A7
0000003E: 486E FFF4          PEA       $FFF4(A6)
00000042: A844               _X2Fix
00000044: 201F               MOVE.L    (A7)+,D0
00000046: 2A00               MOVE.L    D0,D5
00000048: 594F               SUBQ.W    #$4,A7
0000004A: 484B               BKPT      #$3
0000004C: A844               _X2Fix
0000004E: 201F               MOVE.L    (A7)+,D0
00000050: 2C00               MOVE.L    D0,D6
00000052: 4CDF 0C78          MOVEM.L   (A7)+,D3-D6/A2/A3
00000056: 4E5E               UNLK      A6
00000058: 4E75               RTS
0000005A

I don't know 68000 assembler, but I can see that FixIt1 and FixIt2 are
identical up to the instruction before returning.  This does not seem
correct since one is passed a pointer and one is passed a 10 byte
extended value.  Just before the last _X2Fix in main is this
instruction: BKPT.  Is that the illegal instruction?   What is it?

The workaround as with the 6.0.1 version of the bug is to always
use X2Fix on a local copy of an extended value, not a pointer or a
reference.

+++++++++++++++++++++++++++

>From [e-mail] (N.Perry)
Date: Wed, 13 Apr 1994 09:08:22 GMT
Organization: School of Maths & Info. Sci., Massey University, Palmerston North, NZ


Jeff DuMonthier <[e-mail]> has posted that a bug
in the compilation of extended *arg being passed to X2Fix is still in
7.0. I looked into this and discovered that the problem is even worse
than Jeff thought :-( The following function:

Fixed FixIt5(extended *x)
{
        extended *h = x;
        Fixed f = X2Fix(*h);          //< ouch!
        return f;
}

produces the code:

FixIt5(long double *):
00000000: 4E56 0000          LINK      A6,#$0000
00000004: 48E7 1020          MOVEM.L   D3/A2,-(A7)
00000008: 202E 0008          MOVE.L    $0008(A6),D0
0000000C: 2440               MOVEA.L   D0,A2
0000000E: 594F               SUBQ.W    #$4,A7
00000010: 484A               BKPT      #$2
00000012: A844               _X2Fix
00000014: 201F               MOVE.L    (A7)+,D0
00000016: 2600               MOVE.L    D0,D3
00000018: 4CDF 0408          MOVEM.L   (A7)+,D3/A2
0000001C: 4E5E               UNLK      A6
0000001E: 205F               MOVEA.L   (A7)+,A0
00000020: 584F               ADDQ.W    #$4,A7
00000022: 4ED0               JMP       (A0)

Now a BKPT is not very good for your Mac - I think a crash is
inevitable :-( (For 68K hackers, the hex 484A looks like an attempt to
code up PEA (A2), a non-existant instruction...)

I'll send it off to Symantec tech support.

Hope this helps someone *before* their Mac locks up!

Cheers,
    Nigel

--
Dr Nigel Perry                    Email: [e-mail]
Department of Computer Science    Tel: [phone] ext 8900
Massey University                 Fax: [phone]
Palmerston North, New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (Ron Hunsinger)
Date: Sat, 16 Apr 94 17:20:27 PST
Organization: Berkeley Macintosh Users Group

[e-mail] (N.Perry) writes:

>Now a BKPT is not very good for your Mac - I think a crash is
>inevitable :-( (For 68K hackers, the hex 484A looks like an attempt to
>code up PEA (A2), a non-existant instruction...)

PEA (A2) is a perfectly valid instruction, exactly equivalent in speed,
code size, and function to MOVE.L A2,-(A7).  Either would have been
correct in this sequence.

I think you meant to say "484A looks like an attempt to code up PEA A2,
which is a non-existent instruction."

(Actually, it looks like they were trying to split the difference between
PEA (A2) [4852] and MOVE.L A2,-(A7) [1F0A].  They got the sum of 4840 [PEA]
and 000A [A2].  If they had started with 1F00 [MOVE.L ,-(A7)], or added
0012 [(A2)], they would have been OK.)

-Ron Hunsinger

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 17 Apr 1994 21:26:59 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <[e-mail]>,
Ron Hunsinger <[e-mail]> wrote:

>(Actually, it looks like they were trying to split the difference between
>PEA (A2) [4852] and MOVE.L A2,-(A7) [1F0A].  They got the sum of 4840 [PEA]
>and 000A [A2].  If they had started with 1F00 [MOVE.L ,-(A7)], or added
>0012 [(A2)], they would have been OK.)

Do you guys really know all these opcodes by heart ? I'm amazed!

--
Francois Pottier
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************